Day2 - GPT 陪我讀 W3C Trace Context Ch1
Day3- GPT 陪我讀 W3C Trace Context Ch2
Day4- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第一部份
Day5- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第二部份
Day6- GPT陪我讀 W3C Trace Context Ch3 追蹤上下文 HTTP 標頭格式 第三部份
Day7- GPT 陪我讀 W3C Trace Context Ch4
Day8- GPT 陪我讀 W3C Trace Context Ch5-6

Ch5 其他通訊協議

雖然追踪上下文是為 HTTP 定義的，但作者承認它對其他通訊協議也很重要。這一規範的擴展，以及外部組織製定的規範，為其他協議定義了追踪上下文序列化和反序列化的格式。請注意，這些擴展可能與此規範有著不同的成熟度。

請參考 trace-context-protocols-registry 以獲得其他協議的追踪上下文實現的詳細資料。

解釋說明：
這一章節提到，儘管"追踪上下文"主要是為 HTTP 定義的，但其概念和應用對其他的通訊協議也是有價值的。這意味著，該規範不只適用於 HTTP，它可以擴展到其他的通訊協議上。但要注意的是，這些針對其他協議的擴展版本可能和原始規範在技術成熟度上有所不同。如果想要查看這些擴展或者其他協議上的追踪上下文的實現，可以參考提到的 registry。

摘要與總結：
追踪上下文，雖主要為 HTTP 所設計，其概念也適用於其他通訊協議。對此，有一些擴展版本或由外部組織制定的規範適用於其他協議，但它們的成熟度可能與原始規範不同。要查詢這些協議的具體實現，可以參考相關的註冊表。

Ch6 隱私考量

將header傳播到下游服務的要求，以及儲存這些header的值，都可能帶來隱私問題。追踪供應商絕對MUST NOT使用 traceparent和tracestate欄位儲存任何個人身份或其他敏感資訊。這些欄位的唯一目的是啟用追踪關聯。

供應商MUST評估header濫用的風險。本節提供了一些考慮因素和與儲存和傳播這些header相關的風險的初步評估。追踪供應商可以選擇在允許追踪系統執行可能傳播或儲存這些欄位的程式碼之前，檢查並從字段中移除敏感資訊。然而，所有的修改都應該遵從本規範中定義的修改列表。

解釋說明：
這一章節專門討論在使用追踪上下文時應該考慮的隱私問題。由於追踪資訊會在系統中傳播和儲存，這增加了敏感資訊被濫用的風險。因此，該規範明確指出，追踪資訊不應該包含任何可以識別個人的資訊或其他敏感資訊，其唯一的目的是為了追踪關聯。同時，供應商應該評估這些header可能被濫用的風險，並在必要時移除這些資訊。

6.1 traceparent 欄位的隱私

traceparent 欄位由隨機生成的數字組成。如果隨機數生成器使用如IP地址這樣的任何用戶可識別資訊作為初始狀態，則這些資訊可能會被暴露。隨機數生成器MUST NOT依賴任何可能被用來識別用戶的資訊。

traceparent字段的另一個隱私風險是能夠關聯作為單一交易的多次請求。下游服務可能會追踪和關聯單一交易中的兩次或多次請求，並可能基於另一個請求的資訊對請求的呼叫者做出假設。

需要注意的是，traceparent 欄位的這些隱私問題在實際操作中比較理論化。一些發起或接收請求的服務MAY會選擇重新開始一個 traceparent 欄位，以完全消除這些風險。供應商SHOULD該找到一種方法，將分散式追踪的重新開始次數減到最少，以促進追踪供應商之間的互操作性。而不是重新開始，可以使用不同的技術。例如，服務可以定義上游和下游連接的信任邊界，以及任何請求可能帶來的暴露級別。例如，供應商可能只對來自或發往外部服務的認證請求重新開始 traceparent。

服務還可以定義一個算法和審計機制，以驗證 traceparent 欄位中的入站或出站隨機數的隨機性。請注意，這種算法是特定於服務的，不是本規範的一部分。一個例子可能是一種時間算法，其中應用了一個可逆的哈希函數到當前的時鐘時間。接收者可以驗證時間是否在雙方認同的邊界內，這意味著隨機數是使用所需的算法生成的，事實上並不包含任何個人身份信息。

解釋說明：
這節內容主要談論 traceparent 欄位的隱私考慮。traceparent 是由隨機生成的數字組成，而生成這些隨機數字的方法不應該依賴任何可能識別用戶的資訊。此外，還提到了如何避免或最小化利用 traceparent 進行關聯性攻擊的風險，例如重新開始追踪或在特定情況下定義信任邊界。

6.2 tracestate欄位的隱私

tracestate 欄位中的任何鍵都可能包含任何不透明的值。此標頭的主要目的是在不同的分散式追踪系統中提供額外的供應商特定的追踪識別資訊。

供應商MUST NOT應在 tracestate header中包括任何可以識別個人身份的資訊。

對個人資訊暴露極為敏感的供應商可能會實施選擇性地移除與未知鍵相對應的值。供應商SHOULD NOT改變tracestate欄位，因為這違背了允許多個追踪系統合作的目的。

解釋說明：
此段落主要闡述 tracestate 欄位的隱私考量。這個字段可以包含任何供應商特定的追踪識別資訊，用於在不同的分散式追踪系統間進行通訊。但是，供應商不能在其中加入任何個人身份資訊。對於那些特別關心隱私的供應商，他們可以選擇刪除未知的鍵值對，但一般情況下，供應商不應該修改這個欄位，因為這會妨礙不同的追踪系統間的協同工作。

6.3 其他風險

當供應商在回應中包含 traceparent 和 tracestate header時，這些值可能不小心被傳遞給跨域的呼叫者。供應商應確保只在回應參與追踪的系統時才包含這些回應header。

解釋說明：
這一段是在說明，如果供應商在他們的回應中包含了 traceparent 和 tracestate 標頭，那麼這些標頭有可能被不小心地傳送給其他的、非原始的跨域系統。所以，為了防止這種情況，供應商應該只在回應那些真正參與追踪的系統時，才加入這些header。

摘要回顧

1. traceparent 欄位的隱私考慮：

   • traceparent 欄位主要由隨機生成的數字組成。如果隨機數生成器使用任何可能識別用戶的資訊（如 IP 地址）作為種子狀態，這些資訊可能會被洩露。
   • 透過 traceparent 欄位，下游服務可能會追踪和關聯單一交易的多個請求。
   • 建議供應商尋找方法減少分散追踪的重新啟動，以促進追踪供應商之間的互操作性。

2. tracestate 欄位的隱私考慮：

   • tracestate 欄位可能包含任何不透明的值。這個欄位的主要目的是提供跨不同分散追踪系統的供應商特定的追踪識別資訊。
   • 供應商絕對不應在 tracestate header中包括任何個人身份資訊。
   • 非常重視個人資訊保護的供應商可能會選擇刪除與未知鍵相對應的值。

3. 其他風險：

   • 當供應商在回應中包含 traceparent 和 tracestate header時，這些資訊有風險被不當地傳送給跨域的系統。

總結

第6章重點闡述了使用 traceparent 和 tracestate header時的隱私風險。在分散追踪中，這些標頭的主要目的是用於追踪協同，而非儲存或傳送任何個人識別或敏感資訊。供應商必須確保他們在使用這些header時，不會讓任何個人資訊被洩露，且在回應跨域請求時，應特別小心。